FIG. 1 is a network architecture of a long term evolution (LTE) system which is the related art mobile communication system has evolved from the existent UMTS system and a basic standardization therefor is undergoing in 3GPP.
The LTE network may be divided into evolved UMTS terrestrial radio access network (E-UTRAN) and core network (CN). The E-UTRAN includes a terminal (User Equipment; UE), a base station (Evolved Node B; eNB), an access gateway (aGW) located at the end of the network to be connected to an external network. The aGW may be divided into a portion of handling a user traffic and a portion of processing a control traffic. Here, a new interface may be used for the communication between the aGW for processing the user traffic and the aGW for processing the control traffic. One or more cells may exist in one eNB. An interface for transmission of the user traffic or control traffic may be used between eNBs. The CN may include an aGW, a node for a user registration of other UEs and the like. An interface may be used to identify the E-UTRAN and CN.
FIG. 2 is an architecture of a radio interface protocol control plane between a terminal and an E-UTRAN based upon the 3GPP radio access network standard, and FIG. 3 is an architecture of a radio interface protocol user plane between a terminal and an E-UTRAN based upon the 3GPP radio access network standard.
Hereinafter, the architecture of radio interface protocols between the terminal and the E-UTRAN will be described with reference to FIGS. 2 and 3.
The radio interface protocol has horizontal layers comprising a physical layer, a data link layer and a network layer, and has vertical planes comprising a user plane for transmitting data information and a control plane for transmitting a control signaling. The protocol layers can be divided into a first layer (L1), a second layer (L2) and a third layer (L3) based on three lower layers of an Open System Interconnection (OSI) standard model widely known in communications systems. Such radio interface protocols may exist as a pair between the terminal and the E-UTRAN, to manage data transmissions over interfaces.
Hereinafter, each layer in the radio protocol control plane in FIG. 2 and the radio protocol user plane in FIG. 3 will be described.
A first layer, as a physical (PHY) layer, provides an information transfer service to an upper layer using a physical channel. The physical layer is connected to its upper layer, called a Medium Access Control (MAC) layer, via a transport channel. The MAC layer and the physical layer exchange data via the transport channel. Here, the transport channels may be divided into a dedicated transport channel and a common transport channel depending on whether the transport channel is shared. Data is transferred via a physical channel between different physical layers, namely, between the physical layer of a transmitting side and the physical layer of a receiving side.
Various layers exist in the second layer. First, a medium access control (MAC) layer serves to map different logical channels to different transport channels, and also performs a logical channel multiplexing for mapping several logical channels to one transport channel. The MAC layer is connected to an upper radio link control (RLC) layer via a logical channel. Logical channels are is divided according to a type of information to be transmitted into a control channel for transmitting control plane information and a traffic channel for transmitting user plane information.
The RLC layer of the second layer manages segmentation and concatenation of data received from an upper layer to appropriately adjust a data size such that a lower layer can send data over an interface. Also, the RLC layer provides three operation modes, including a transparent mode (TM), an un-acknowledged mode (UM) and an acknowledged mode (AM), so as to guarantee various quality of service (QoS) requirements of each radio bearer (RB). In particular, the RLC layer operating in the AM mode (hereinafter, referred to as AM RLC layer) performs a retransmission using an automatic repeat and request (ARQ) function for a reliable data transmission.
A packet data convergence protocol (PDCP) layer located at the second layer is used to efficiently transmit IP packets, such as IPv4 or IPv6, on a radio interface with a relatively small bandwidth. For this purpose, the PDCP layer reduces the size of an IP packet header which is relatively great in size and includes unnecessary control information, namely, performs a function called header compression. Accordingly, only necessary information can be included in the header part of data for transmission, so as to increase a transmission efficiency of a radio interface.
A radio resource control (RRC) layer located at the lowermost portion of the third layer is only defined in the control plane. The RRC layer controls logical channels, transport channels and physical channels in relation to configuration, re-configuration and release of Radio Bearers (RBs). Here, the RB denotes a logical path that the L2 layer provides for data transmission between the terminal and the UTRAN. In general, the establishment of the RB refers to stipulating the characteristics of protocol layer and channel required for providing a specific service, and setting the respective detailed parameters and operation methods. The RBs are divided into a signaling RB (SRB) and a data RB (DRB). The SRB is used as a path for transmission of RRC messages in the C-plane, while the DRB is used as a path for transmissions of user data in the U-plane.
Hereinafter, the RLC layer will be described in more detail. The RLC layer provides three modes, such as the TM, UM and AM, as mentioned above. The RLC layer rarely performs a function in the TM, and thus UM and AM will only be described herein. The UM RLC adds a protocol data unit (PDU) header including a sequence number (SN) to each PDU for transmission, such that a receiving side can be known as to which PDU has been lost during transmission. Due to such function, the UM RLC manages, in the user plane, the transmission of multimedia data or the transmission of real-time packet data, such as voice (e.g., VoIP) or streaming in a packet service domain (hereinafter, referred to as a PS domain), while managing, in the control plane, the transmission of an RRC message, which does not need a reception acknowledgement, among RRC messages sent to a specific terminal or specific terminal group within a cell.
Similarly, the AM RLC constructs a PDU by adding a PDU header including an SN upon the construction of PDU. Unlike the UM RLC, a receiving side acknowledges a PDU sent by a transmitting side. The receiving side acknowledges in order to request a retransmission of unsuccessfully received PDU from the transmitting side. Such retransmission function is the most important characteristic of the AM RLC. Thus, the AM RLC aims to guarantee an error-free data transmission via the retransmission. Under the purpose, the AM RLC usually manages a non-real-time packet data transmission, such as TCP/IP of PS domain, in the user plane, while managing a transmission of RRC message, which requires a reception acknowledgement, among RRC messages transmitted to a specific terminal within a cell in the control plane.
From the perspective of direction, the UM RLC is used for a unidirectional communication, while the AM RLC is used for a bi-directional communication due to a feedback from a receiving side. From the structural perspective, there is a difference, namely, the UM RLC is configured such that one RLC entity performs transmission or reception while the AM RLC is configured such that both transmitting side and receiving side exist in one RLC entity. The complicated configuration of the AM RLC is due to the retransmission. The AM RLC includes a retransmission buffer for managing the retransmission, in addition to a transmission/reception buffer. Also, the AM RLC performs various functions, such as using transmitting and receiving windows for a flow control, polling for a transmitting side to request status information from a receiving side of an RLC entity, sending a status report for a receiving side to report its buffer state to a transmitting side of a peer RLC entity, constructing a status PDU for delivering status information, and the like. The AM RLC also needs various protocol parameters, such as status variables and a timer, in order to support the functions. A PDU, such as status report or status PDU, which is used for controlling the data transmission in the AM RLC, is referred to as ‘Control PDU’, and a PDU used for transferring user data is referred to as ‘Data PDU’.
An RLC data PDU in the AM RLC may be divided into AMD PDU and AMD PDU segment, in detail. The AMD PDU segment has part of data included in the AMD PDU. In the LTE system, a maximum size of a data block is changeable every time a terminal sends the data block. Hence, after a transmitting side AM RLC entity constructs a 200-byte AMD PDU at a specific time and transmits the constructed AMD PDU, when the transmitting side AM RLC receives NACK from a receiving side AM RLC and thereby tries to retransmit the AMD PDU, if a maximum size of data block to be actually transmittable is 100 bytes, the same AMD PDU cannot be sent as it is. In this case, the AMD PDU segment is used. The AMD PDU segment denotes that the corresponding AMD PDU is segmented into smaller units. During the procedure, the transmitting side AM RLC entity divides the AMD PDU into the AMD PDU segments and transmits the AMD PDU segments over several transmission time intervals. The receiving side AM RLC entity then restores the AMD PDU from the received AMD PDU segments.
If there is unsuccessfully (incompletely or incorrectly) received data, the receiving side AM RLC requests a retransmission of such data from the transmitting side AM RLC, which is referred to as ‘status report’. The status report is sent by using STATUS PDU, which is one of control PDUs.
FIG. 4 is a format of STATUS PDU currently used in the LTE system. In FIG. 4, a horizontal axis denotes a length of an RLC STATUS PDU with 8 bits, namely, 1 octet.
Each field of the RLC STATUS PDU will now be described.
1. Data/Control (D/C) field: 1 bit                This field indicates whether a corresponding RLC PDU is either RLC data PDU or RLC control PDU.        
2. Control PDU type (CPT) field: 3 bits                This field indicates what type a corresponding control PDU is. The RLC control PDU currently defines only the STATUS PDU.        
3. Acknowledgement Sequence Number (ACK_SN)                Two types of ACK_SN will be defined as follows.                    1-1) A type of ACK_SN is an RLC SN of a first PDU whose information is not included in a STATUS PDU.            1-2) Upon receiving the STATUS PDU, a transmitting side determines that all the PDUs among PDUs up to the PDU with ACK_SN-1 have successfully been received by a receiving side, excluding PDUs indicated in the STATUS PDU with NAC_SN or portions of PDUs indicated in the STATUS PDU with NACK_SN, SOstart and SOend.                        
Such ACK_SN was applied to embodiments of FIGS. 6 and 8 according to the present invention.
2-1) Another type of ACK_SN is an RLC SN of a first PDU whose information is included in a STATUS PDU.
2-2) Upon receiving the STATUS PDU, the transmitting side determines that all the PDUs among PDUs up to the PDU with the ACK_SN have successfully been by the receiving side, excluding PDUs indicated in the STATUS PDU with NACK_SN or portions of PDUs indicated in the STATUS PDU with NACK_SN, SOstart and SOend.
Such ACK_SN was applied to embodiments of FIGS. 7 and 9 according to the present invention.
4. Extension 1 (E1): 1 bit
This indicates whether there is another NACK_SN element following a current NACK_SN element (i.e., indicated with NACK_SN or with NACK_SN, SOstart and SOend).
5. NACK_SN (Negative acknowledgement Sequence Number)
This is an RLC SN of an unsuccessfully received AMD PDU or AMD PDU segment.
5. Extension 2 (E2): 1 bit
This indicates whether there are SOstart and SOend fields corresponding to a current NACK_SN.
6. Segment Offset Start (SOstart) and Segment Offset End (SOend)
These are used when only a part (segment) of PDU with NACK_SN is NACK. A first byte of the part corresponds to the SOstart and the last byte thereof corresponds to the SOend.
In the meantime, the receiving side AM RLC cannot always trigger a STATUS PDU, but can trigger a status reporting only when a specific condition is met. Such condition is referred to as ‘status reporting trigger’, and the LTE system currently uses two conditions as follows.
The first condition is a polling of a transmitting side.
That is, when desiring to receive a status report from a receiving side, the transmitting side AM RLC sets a poll bit for an RLC data PDU for transmission.
The receiving side AM RLC then triggers the status report upon receiving the poll bit set RLC data PDU.
The second condition is a detection of an unsuccessful reception of RLC data PDU.
That is, upon detecting an unsuccessfully received RLC data PDU (i.e., AMD PDU or AMD PDU segment) after completing a HARQ reordering, the receiving side AM RLC triggers the status report.
In addition, when the status report is triggered, the receiving side AM RLC sends a reception buffer state to the transmitting side using a STATUS PDU. Here, is the STATUS PDU includes information up to the last PDU (=VR(MS)) among PDUs within the range of a PDU (=VR(R)) with a start point of a receiving window to a HARQ reordering completed PDU. Here, the VR(R) and VR(MS) denote state variables, which are managed by the receiving side AM RLC and used for a receiving window, a status report and the like. Among others, the receiving AM RLC manages additional state variables.
Such additional state variables of the receiving side AM RLC are described as follows.                VR(R): Receive state variable.                    It hold a value of a sequence number (SN) of an AMD PDU subsequent to the last AMD PDU among AMD PDUs received in-sequence.            It is a first AMD PDU among AMD PDUs which are not completely (successfully) received by the receiving side AM RLC.            It serves as the lower edge of the receiving window.            It is initially set to 0. When completely receiving an AMD PDU with SN=VR(R), it is updated to a value of SN of a first incompletely received AMD PDU subsequent to the AMD PDU.                        VR(MR): Maximum acceptable receive state variable.                    It holds a value of SN of the first AMD PDU among AMD PDUs outside a receiving window.            It serves as the higher edge of the receiving window.            It is updated, for example, to VR(MR)=VR(R)+AM_Window_size when the VR(R) is updated.                        VR(X): T_reordering state variable                    It holds a value of SN of an RLC data PDU subsequent to an RLC data PDU which triggered a T_reordering as a timer for managing a HARQ reordering.            A receiving side AM RLC drives the T_reordering upon receiving an out-of-sequence RLC data PDU under a condition that no T_reordering is triggered, and sets the VR(X) to the value of SN of an RLC data PDU subsequent to the RLC data PDU.                        VR(MS): Maximum status transmit state variable                    This state variable is used for including in a STATUS PDU information only related to RLC data PDUs for which the HARQ reordering is completed.            It is initially set to 0, and upon completely receiving an AMD PDU with SN=VR(MS), it is updated to a value of SN of a first incompletely received AMD PDU following the AMD PDU.                        Upon the T_reordering expired, it is updated to a value of SN of a first incompletely received AMD PDU among AMD PDUs higher than VR(X). ACK_SN is set to the VR(MS) so as to construct a STATUS PDU.        VR(H): highest received state variable                    It holds a value of the very next SN of the highest SN among RLC data PDUs received by the receiving side AM RLC, namely, a value of SN of an RLC data PDU which is first unsuccessfully received by the receiving side AM RLC.            It is initially set to 0, and upon receiving an RLC data PDU higher than VR(H), it is updated to a value of SN of an RLC data PDU subsequent to the RLC data PDU.                        
Hereinafter, a logical channel prioritization (LCP) performed by the MAC layer will be described.
When several radio bearers (RBs) are multiplexed and transmitted over one transport channel, an LTE terminal is configured such that its MAC layer decides an amount of transmission data for each RB, based upon the following rules, with respect to a given radio resource, for every transmission time interval (TTI).                1. The MAC layer decides an amount of transmission data for multiplexed RBs in a decreasing order of each logical channel priority (LCP), and then decides a transmission amount as much as data corresponding to a maximum prioritized bit rate (PBR) for each RB.        2. If any radio resources remain, the MAC layer decides the amount of transmission data for the multiplexed RBs in the decreasing order of each LCP.        
Here, 1 to 8 LCPs are currently discussed, and 1 denotes the highest priority and 8 denotes the lowest priority. PBR denotes a minimum bit rate guaranteed for a corresponding RB, which means that the LTE system can support such degree of bit rate even under a very bad radio environment. The PBR may be set within the range of 0 to infinity.
In the meantime, LCP and PBR of each RB are sent from a network RRC to a terminal RRC via an RB setup message upon initially setting the RB. After receiving the RB setup message, the terminal RRC then sets necessary RBs and sends information on LCP and PBR of each RB to a terminal MAC. The MAC having received such information decides a transmission amount of each RB with respect to a given radio resource for every TTI, base upon such rules.